Description of Change

This PR fine tunes the disposal steps of a co-owned object pair. There are a few scenarios:

1. A managed creates and owns an underlying native instance. (SKBitmap)
   When the managed object is disposed, destroy the native object.
2. A native object creates a child native object that is managed on the native side. (SKSurface controls SKCanvas)
   When then the managed object destroys the native surface, the native canvas is also destroyed. There may be a case where a brand new native canvas is constructed in the same place - before the managed canvas is disposed. We have to make sure that e dispose the managed object before we destroy the native object.
3. A native object "creates" a managed object that is managed from the native side. (SKSvgCanvas controls SKManagedStream)
   The managed object creates the native object, but the native object owns the managed object. This means that even when the managed object is disposed, the action is "ignored" and proxied to the native destructor - which will then call back into managed code to dispose the managed object. This is because the native canvas may flush or write closing data into the managed stream.

Scenarios 2 and 3 cause an issue: In one case, the managed SKCanvas needs to be destroyed before destroying the native SkSurface. On the other hand, the native SKSvgCanvas needs to be destroyed before destroying the managed SKManagedStream. So which goes first?

The answer is in the ownership of the handle: In scenario 1, the surface owns its handle and the canvas - which does not own its handle. In scenario 2, the canvas owns its handle and the stream - which does own its handle.

This shows that we need to first dispose all the "reference-only" objects - or the ones that do not own their handle. Then dispose the native object. Finally, clean up any managed objects.

Bugs Fixed

• Fixes [BUG] SKCanvas owned by SKSurface gets disposed #1343

API Changes

None.

Behavioral Changes

See description...

PR Checklist

• Has tests (if omitted, state reason in description)
• Rebased on top of master at time of PR
• Changes adhere to coding standard
• Updated documentation